Columbia Kermit/kermit.zip/newsgroups/misc.19980901-19981211/000250_news@newsmaster….columbia.edu _Mon Nov 2 13:36:38 1998.msg

Internet Message Format | 2020-01-01 | 4KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA27801
    for <[e-mail]>; Mon, 2 Nov 1998 13:36:37 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA14369
    for kermit.misc@watsun; Mon, 2 Nov 1998 13:36:37 -0500 (EST)
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: [e-mail] (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: So, how's the GUI version coming?
Date: 2 Nov 1998 18:36:34 GMT
Organization: Columbia University
Lines: 53
Message-ID: <71ku3i$7f9$[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: watsun.cc.columbia.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:9452

In article <[e-mail]>, Michael Kairys <[e-mail]> wrote:
: Heven't heard mention for quite a while...
:
We're still working on it :-)

Very briefly, the problem is not so much the GUIness per se (which is
of course in itself a "stout" piece of work), but maintaining our base
of common code.

Somewhat less briefly...  As you may know (it's no secret), Kermit 95
is built on the command parser and protocol engine of C-Kermit, which
turn runs on quite literally hundreds of other platforms.  The command
parser forms the basis for the script language -- a major attraction of
Kermit 95 and most other Kermit software -- and so cannot be simply tossed
out in favor of GUI dialogs.  Thus GUI dialogs (thousands of them) must be
*added*.  However, the structure of a Windows application is radically
different from C-Kermit's current structure.  Therefore, to be able to
control Kermit 95 from either a script or GUI dialog panels requires a
massive rewrite of 15 years of code in a way that will work in both
UNIX, VMS, etc, as it does now, and also can fit into the event-queue
structure required by Windows.  This sort of job pretty much requires that
we shut our ears to the world for several months while we concentrate on
this, dare I say, Augean task.

If this was all we had to do, we'd have done it by now.  But there has also
been a neverending series of demands for new features and "compliance" with
this or that new three-letter acronym, not to mention Year 2000, Euro,
assorted security schemes, etc, which can not be ignored.

The current plan is:

 . Finish and release C-Kermit 7.0.
 . Release K95 1.1.18, which will be based on C-Kermit 7.0.

Then the GUI.

Incidentally, I don't necessarily subscribe to the view that All Must Be
GUI.  The command line is quite powerful, flexible, and even user friendly
if you take the time to learn it -- and Kermit 95, like other communications
software, demands that the user invest some time in learning because its
domain is uncontained and uncontrolled.  In the case of Windows 95 and 98,
however, GUIness is important for quite a different reason -- to escape the
countless bugs and aggravating limitations of the Windows console
environment (to name just two: we can't use a Unicode font, and we can't
do graphics emulations such as Tektronix).  So you can be sure this is a
priority for us.

All of this will take quite a few more months.  In the meantime, I like to
think that Kermit 95 is quite useful in its current form.  It has the added
benefit that most of its thousands of functions can be activated without
your hands ever needing to leave the keyboard.

- Frank